As the value and use of information continues to increase, individuals and businesses seek additional ways to process and store information. One option available to users is information handling systems. An information handling system generally processes, compiles, stores, and/or communicates information or data for business, personal, or other purposes thereby allowing users to take advantage of the value of the information. Because technology and information handling needs and requirements vary between different users or applications, information handling systems may also vary regarding what information is handled, how the information is handled, how much information is processed, stored, or communicated, and how quickly and efficiently the information may be processed, stored, or communicated. The variations in information handling systems allow for information handling systems to be general or configured for a specific user or specific use such as financial transaction processing, airline reservations, enterprise data storage, or global communications. In addition, information handling systems may include a variety of hardware and software components that may be configured to process, store, and communicate information and may include one or more computer systems, data storage systems, and networking systems.
Information handling systems are often networked together into networking systems that include a variety of different information handling system types performing different functions within the network. Recently, there has been a rapid growth in network equipment types, as well as types of networking systems. New network architectures, services, equipment and features are added/modified in the market place at a rapid pace. Thus, networking systems are tasked with providing an increased diversity of services using a growing breadth of network architectures, devices, components, and features from different vendors.
A block diagram of a conventional networking system 100 is illustrated in FIG. 1A. The deployed networking system 100 of FIG. 1A is composed of multiple network devices from different vendors. These network devices include servers 104, switch stack 106, storage arrays 108, routers 110, gateways 112, remote wireless controllers 114, access points 116, switches 118, wireless controllers 120, and access points 122. Also shown are virtual machines 124, operating systems 126, and software applications 128 that may be executing on servers 104. A network management system (NMS) 102 may be provided as shown to assist with network management and service provisioning. NMS 102 is a combination of hardware and software components configured to maintain and administer a networking system, and is typically implemented on an information handling system configured as a server or administrator computer that communicates with the various network devices through network router devices 110, switch stack 106 and switches 118 as shown. One example of such a NMS is a Dell OpenManage Network Manager available from Dell Products L.P. of Round Rock, Tex.
NMS systems are challenged with maintaining parity with new network equipment and equipment firmware/software. NMS configuration management functionality can lag months and years behind the network devices available in the market. Moreover a NMS cannot know all the possible ways a user wants to configure a device. Additionally, an increased amount of security maintenance is required for operators granting configuration access on a device by device basis.
Integrating device support into a NMS is tedious, time consuming and expensive. In addition to maintenance of parity, each new device, operation system or command line interface (CLI) command structure typically requires NMS development to start from zero. A development team typically must study the behavior of the devices with regard to factors such as the following: 1) Available application programming interfaces (APIs) such as SNMP, CLI, and Web APIs; 2) Timing and sequence of management messages from NMS to/from device, including command count per message, time delay between messages, and different command and parameter values; and 3) device responses between commands, such as success responses, error responses, error codes, and interrupts. For all the variances in devices and firmware, NMS development teams are required to perform analysis, design, and test. Device behavior, changes, timings, sequences are not documented in a machine readable format.
Additionally, existing protocols have limited impact on integration. SNMP is an active standard that enables machine to machine communication using a protocol. Existing SNMP protocols are a cumbersome path to use for network configuration. SNMP is a protocol designed for computer to computer interface but was not designed for user interface (Graphical, Command Line, or Web). Not all device configuration options are supported by SNMP. Furthermore, use of SNMP does not match natural configuration flow of device interfaces for example. SNMP MIBs (Management Information Base) come from different standards that evolved overtime for diverse market applications.
Furthermore, CLI API conversion is non-standard and not portable. A majority of network operators and others use CLI to configure devices, and CLI is the protocol of choice for human to machine interface. Thus, CLI is the natural forum of communication designed for the network device, and CLI is commonly used by network administrators to manage and configure devices. CLI is also used CLI for scripting and automation and is also typically available on network devices for free. Network equipment vendors typically enable management of a new feature in CLI first before any other management interface. Therefore, CLI is usually the first interface to implement new features for a product, while SNMP MIBs, on the other hand, do not implement every CLI command.
However, CLI command behaviors, timings, sequences are not documented in a machine readable format. Each vendor has its own CLI structure, syntax and operation modes. Moreover a given vendor's CLI can vary between products. Finally CLI can vary between firmware versions of the same product. License keys installed on a device can also change the CLI. Industry standard CLI definitions to be implemented are not available today and not envisioned for the future. Thus, CLI can be considered a unique management interface experience associated with a given vendor's equipment.
FIG. 1B illustrates a traditional user interface (UI) chassis view 150 displayed on a display device for a network device configured as a switch. As shown in FIG. 1B, the content and topology of traditional chassis view 150 is limited to discrete information such as port status and packet rate.